home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1453.txt < prev    next >
Text File  |  1994-08-01  |  24KB  |  563 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        W. Chimiak
  8. Request for Comments: 1453                                         BGSM
  9.                                                              April 1993
  10.  
  11.  
  12.          A Comment on Packet Video Remote Conferencing and the
  13.                         Transport/Network Layers
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  It does
  18.    not specify an Internet standard.  Distribution of this memo is
  19.    unlimited.
  20.  
  21. Abstract
  22.  
  23.    The new generation of multimedia applications demands new features
  24.    and new mechanisms for proper performance.  ATM technology has moved
  25.    from concept to reality, delivering very high bandwidths and new
  26.    capabilities to the data link layer user.  In an effort to anticipate
  27.    the high bandwidth-delay data link layer, Delta-t [Delta-t], NETBLT
  28.    [RFC 988], and VMTP [RFC 1045] were developed.  The excellent
  29.    insights and mechanisms pioneered by the creators of these
  30.    experimental Internet protocols were used in the design of Xpress
  31.    Transfer Protocol (XTP) [XTP92] with the goal of eventually
  32.    delivering ATM bandwidths to a user process.  This RFC is a vehicle
  33.    to inform the Internet community about XTP as it benefits from past
  34.    Internet activity and targets general-purpose applications and
  35.    multimedia applications with the emerging ATM networks in mind.
  36.  
  37. 1.  Introduction
  38.  
  39.    Networking is no longer synonymous with analog telephony.  High-
  40.    performance lower-layer networks have made possible exciting new
  41.    applications: collaboratory environments, distributed client/server
  42.    computing, remote conferencing, teleclassrooms, and distributed
  43.    life-sciences imaging.  These applications normally demand a great
  44.    deal of bandwidth and often create operating system bottlenecks.
  45.    Enabling these new multimedia applications entails delivering
  46.    bandwidth to the applications, not just having bandwidth available on
  47.    the network.  This statement may appear obvious, but often solutions
  48.    at the transport layer are satisfied by having bandwidth at that
  49.    layer without sufficient sensitivity to higher-layer access to the
  50.    bandwidth.  The unavailability of bandwidth at upper layers is
  51.    becoming the real issue as the networks are becoming a high-
  52.    performance virtual backplane without concomitant high-performance
  53.    control schemes.  It appears that new services are needed that
  54.    require communication with all layers.  The ATM architecture calls
  55.  
  56.  
  57.  
  58. Chimiak                                                         [Page 1]
  59.  
  60. RFC 1453             Comments on Video Conferencing           April 1993
  61.  
  62.  
  63.    for such an integrated control scheme.
  64.  
  65. 2.  Remote Conferencing
  66.  
  67.    The challenges of remote conferencing is an application whose
  68.    challenges may be met at the data link layer by the emerging
  69.    broadband networks.  If so, important medical applications such as
  70.    medical imaging for diagnosis and treatment planning would be
  71.    possible [CHIM92].  Remote conferencing would permit imaging
  72.    applications for life sciences through the use of national resource
  73.    centers.  Collaboratory conferences in molecular modeling, design
  74.    efforts, and visualization of data in numerous disciplines could
  75.    become possible.
  76.  
  77.    At the Second Packet Video Workshop, held December, 1992, at MCNC in
  78.    the Research Triangle Park, North Carolina, a recurrent theme was the
  79.    use of multimedia in remote conferencing.  Its applications included
  80.    the use of interactive, synchronized voice and video transmission,
  81.    multicast transmission, data transfer, graphics transmission,
  82.    noninteractive video and audio transmission, and data base query
  83.    within a virtually shared workspace.  A few participants doubted the
  84.    ability of current computer networks to handle these multimedia
  85.    applications and preferred only connection-oriented, circuit-switched
  86.    services.  Most participants, however, looked forward to using an
  87.    integrated network approach.
  88.  
  89. 2.1.  Remote Conferencing Functions and Requirements
  90.  
  91.    Remote conferencing as seen at the workshop requires a set of
  92.    functions.  It must provide session scheduling that deals with
  93.    initiating a session, joining in-progress sessions, leaving a session
  94.    without tearing it down if there are multiple participants, and
  95.    terminating a session.
  96.  
  97.    The remote-conferencing session needs a control subsystem that is
  98.    either tightly controlled for an n-to-n connection for two to 15
  99.    participants, or loosely controlled for a 1-to-n connection for any
  100.    number of participants.  The Multipeer-Multicast Consortium is
  101.    working on defining the control requirements and the mechanisms for
  102.    control.  At the Packet Video Workshop, one participant presented a
  103.    conference control protocol (CCP) shown in Figure 1 [CCP92].  In this
  104.    architecture the CCP controls the Network Voice Protocol (NVP)
  105.    [RFC741] and the Packet Video Protocol (PVP) [PVP81] over the
  106.    experimental Internet Stream Protocol, Version 2 (ST-II) [RFC1190]
  107.    rather than IP.
  108.  
  109.    Latency and intramedia synchronization and intermedia synchronization
  110.    (lip-sync) are critical for the interactive voice and video streams
  111.  
  112.  
  113.  
  114. Chimiak                                                         [Page 2]
  115.  
  116. RFC 1453             Comments on Video Conferencing           April 1993
  117.  
  118.  
  119.    of remote conferencing.  Client/server applications including data
  120.    base operations are equally important.  The ability to display
  121.    noninteractive video and high-resolution graphics is necessary.
  122.  
  123.    As with most applications, security will eventually be an issue.  At
  124.    the very least, there must be a mechanism to determine who can find
  125.    out what about conference and who can join a conference.  This
  126.    determination will be part of an upper-layer protocol.
  127.  
  128.       +--------------+ +--------+ +-----+ +------------+
  129.       |Teleconference| |  File  | |Email| |   Domain   |
  130.       |   (CCP)      | |Transfer| |     | |Name Service|
  131.       +----+-------+-+ +-----+--+ +-+---+ +-----+------+
  132.            |       |         |__  __|           |
  133.            |       |            ||              |
  134.      +-----+--+ +--+-----+    +-++-+       +----+---+
  135.      |Network | | Packet |    | T  |       |    U   |
  136.      | Voice  | | Video  |    | C  |       |    D   |
  137.      |Protocol| |Protocol|    | P  |       |    P   |
  138.      +---+----+ +--+-----+    +-+--+       +--+-----+
  139.          |__     __|            |__         __|
  140.             |   |                  |       |
  141.           +-+---+--+             +-+-------+-+
  142.           | Stream |             |     I     |
  143.           |Protocol|             |     P     |
  144.           +---+----+             +---+-------+
  145.               |                      |
  146.         +-----+----------------------+----+
  147.         |IEEE_802.X,FDDI,DARTnet,ATOMIC...|
  148.         +---------------------------------+
  149.  
  150.           Figure 1: The Connection Control Protocol Architecture
  151.  
  152.    The solutions must range in geography from single machines through
  153.    LAN, CAN, MAN, WAN conferences, as well as in data content from PCs
  154.    to high-end workstations.  Implicit in the scaling is the notion of
  155.    product and application interoperability.
  156.  
  157.    Remote conferencing applications should take advantage of future
  158.    network enhancements, as well as the functions provided by ATM, FDDI,
  159.    and SMDS.  Doing so should provide function versus resource trade-
  160.    offs such as cost versus error control and cost versus rate control.
  161.    As a result, the transport layer should be able to provide the
  162.    services offered by the data link layer.
  163.  
  164.    Most of the presentation on remote conferencing indicated a need for
  165.    some degree of multicast functionality, ranging from the 1-to-n, with
  166.    conference membership completely known, to conferences for which
  167.  
  168.  
  169.  
  170. Chimiak                                                         [Page 3]
  171.  
  172. RFC 1453             Comments on Video Conferencing           April 1993
  173.  
  174.  
  175.    existence of a group is known, but exact membership is not.
  176.  
  177.    In remote conferencing, it is preferable to use one network for all
  178.    information traffic.  This network should have an offered quality of
  179.    service (QOS) criteria to accommodate tradeoff metrics, which would
  180.    include guaranteed throughput, connection reliability, high call-
  181.    completion rate, few dropped calls, tolerable error rate, varying
  182.    degrees of compression on the video and audio streams, and tolerable
  183.    motion artifacts, flow control, and latency.  The QOS should be an
  184.    input to the transport layer from the application or transport
  185.    service user.
  186.  
  187.    The compression/coding function should provide time-stamping and
  188.    packetizing information, as well as real-time echo cancellation.
  189.    These functions are usually at the presentation and session layer of
  190.    the Open System Interconnection (OSI) model or the at the application
  191.    in some Internet models, but not the transport layer.
  192.  
  193. 3.  Potential Solutions
  194.  
  195.    RFC 1193 deals with the requirements of real-time communications,
  196.    which include some of the same capabilities [RFC1193].  But the
  197.    requirements articulated create the necessity for new
  198.    transport/network protocols.  The new protocols under development by
  199.    the Audio Visual Transport [SCHU92] (RTC, RTCP), and other protocols
  200.    in this area (ST-II) suggest an architecture like that shown in
  201.    Figure 2.
  202.  
  203.    These approaches may work.  However, they encourage a discipline that
  204.    creates a protocol for each new class of application.  Another
  205.    approach might be to unify the protocols.  It is felt that this is
  206.    one of the main goals of XTP (see Figure 3).
  207.  
  208.    Other design considerations of XTP include the following:
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Chimiak                                                         [Page 4]
  227.  
  228. RFC 1453             Comments on Video Conferencing           April 1993
  229.  
  230.  
  231.              +----------------------+
  232.              |          media       |
  233.              |       application    |
  234.              +--------+----+-+------+
  235.              |        |RTCP| |      |
  236.              |        +----+ |   T  |
  237.              |         RTP   |   C  |
  238.              +-----+-----+   |   P  |
  239.              |ST-II| UDP |   |      |
  240.              +     +-----+---+------|
  241.              |     |       IP       |
  242.              +-----+-------+--------+
  243.              |    Data Link Layer   |
  244.              +----------------------+
  245.  
  246.               Figure 2: One emerging multimedia architecture
  247.  
  248.  
  249.      +--------------+  +--------+ +-----+ +------------++-----------+
  250.      |Teleconference|  |  File  | |Email| |   Domain   ||   media   |
  251.      |              |  |Transfer| |     | |Name Service||application|
  252.      +------+-------+  +----+---+ +--+--+ +-----+------++-----+-----+
  253.             |               |        |          |             |
  254.             +---------------+--------+----------+-------------+
  255.                                      |
  256.                              +-------+--------+
  257.                              |Unified Protocol|
  258.                              +----------------+
  259.                              |Data Link Layer |
  260.                              +----------------+
  261.  
  262.            Figure 3: Another integrated multimedia architecture
  263.  
  264.    (1)  Developing a protocol based on the work and experience of
  265.         the protocol groups such as IETF, which produced NETBLT,
  266.         VMTP, TCP, IP, and UDP.
  267.  
  268.    (2)  Incorporating lessons from Delta-t.
  269.  
  270.    (3)  Observing the design paradigm shift of ATM, SONET, and  VMTP
  271.         in the header, trailer, and information segment construction.
  272.  
  273.    (4)  Targeting the real-time requirements articulated by the
  274.         Department of Defense SAFENET committee and the French
  275.         Ministry of Defense military real-time specification [GAM-T-103].
  276.  
  277.    Mechanisms in XTP allow an application to approach the performance
  278.    desired.  A session-scheduling mechanism for joining and leaving a
  279.  
  280.  
  281.  
  282. Chimiak                                                         [Page 5]
  283.  
  284. RFC 1453             Comments on Video Conferencing           April 1993
  285.  
  286.  
  287.    multicast conference exists.  The XTP mechanism for multicast
  288.    satisfies the loosely controlled session requirements.  The tightly
  289.    controlled session would require the use of multiple XTP
  290.    associations.
  291.  
  292.    The priority mechanism that uses the 32-bit SORT field permits an
  293.    application to prioritize data.  Because XTP is a transport layer,
  294.    this priority mechanism follows through every node tranversed.  There
  295.    is also an out-of-band delivery mechanism.  However, XTP does not
  296.    offer latency control by itself; it just provides a priority
  297.    mechanism.
  298.  
  299.    The selective acknowledgement, fast negative acknowledgement, and
  300.    selective retransmission permit an application to choose an
  301.    appropriate level of error control.  The combination of the priority
  302.    mechanism and these error-control mechanisms is likely to approach
  303.    the latency and synchronization requirements of remote conferencing.
  304.  
  305.    Noninteractive audio and video, as well as graphics presentation, can
  306.    be accommodated in many ways by the application.  It is important
  307.    that the transport layer provides adequate mechanisms to deliver the
  308.    appropriate data streams in a manner compatible with the
  309.    applications.  These applications can probably be accomplished by
  310.    means of extant protocols, as well as XTP.
  311.  
  312.    The scalability of the solution will be a function of the standards
  313.    used.  At the Packet Video Workshop, some of the applications
  314.    sacrificed computer network standards in favor of desired
  315.    performance.  This approach usually impedes scalability.  From the
  316.    explanation of the applications taking this approach, it appeared
  317.    that using XTP would have provided an adequate transport service for
  318.    the applications.
  319.  
  320.    XTP was designed to provide mechanisms to accommodate application
  321.    requirements, that is, the ability to respond to QOS requests.  For
  322.    example, guaranteed throughput may be accomplished by using XTP's
  323.    rate and burst control together with flow control or no flow control.
  324.    Tolerable error rate can be accomplished with partially error
  325.    controlled connections (PECC), a service which can be placed in the
  326.    application or just above the transport layer [PECC92].  Motion
  327.    artifacts and varying degrees of compression should be done above the
  328.    transport layer in coordination with the transport layer or possibly
  329.    in a network management function.
  330.  
  331. 3.1.  Synthesize the Hardware Fabrication Process into the Design
  332.  
  333.    To produce an affordable solution, the hardware fabrication process
  334.    should be a design consideration.  Technologies are evolving too
  335.  
  336.  
  337.  
  338. Chimiak                                                         [Page 6]
  339.  
  340. RFC 1453             Comments on Video Conferencing           April 1993
  341.  
  342.  
  343.    rapidly to assume that a generic protocol design will anticipate all
  344.    fabrication advances, but this fact should not impede use of the
  345.    features of advanced hardware fabrication processes.
  346.  
  347.    System interface problems and VLSI techniques should be considered in
  348.    the specification of the protocol.  An examination of the ATM and
  349.    SONET standards appears to support this philosophy.  Similarly,
  350.    NETBLT and VMTP design efforts seem to support this approach.  XTP
  351.    does use it.
  352.  
  353.    It is very helpful to break down the protocol into parallel-state
  354.    machines for execution on more inexpensive hardware.  This procedure
  355.    reduces the context switching and interrupt handling requirements of
  356.    the hardware, thereby decreasing production costs while producing a
  357.    scalable protocol machine.
  358.  
  359. 4.  Multimedia Applications over XTP
  360.  
  361.    In parallel with the IETF efforts to enable multimedia applications
  362.    such as remote conferencing, the XTP forum members have been
  363.    experimenting with major elements of these applications.
  364.  
  365.  
  366.    (1)  At the University of Virginia, more than 100 simulated voice
  367.         channels were run on an FDDI network [UVAVOICE92].  The
  368.         purpose of this experiment was to test the limits of FDDI
  369.         and a software version of XTP in a simulated interactive
  370.         voice environment.  Multicasted, noninteractive video has
  371.         been supported there for several years.
  372.  
  373.         UVa also has a video-mail demo over XTP/FDDI that uses
  374.         Fluent multimedia interface and standard JPEG compression.
  375.         This PC-based demo delivers full frame, full color, 30
  376.         frames/sec video from any network disk to a remote VGA
  377.         screen.  It is important that users could not discern any
  378.         difference  in  playback  between  a local disk and a remote
  379.         disk.  An Xpress File System (XFS) is used on server and
  380.         client systems.
  381.  
  382.    (2)  The Technical University of Berlin, Germany, reports that
  383.         the coordination, implementation, and operation of
  384.         multimedia services (CIO) of the R&D in Advanced
  385.         Communications Technologies in Europe (RACE) is using XTP as
  386.         a starting point for design [XTPRACE].
  387.  
  388.    (3)  At the Naval Command, Control, and Ocean Surveillance Center
  389.         Research, Development, Test and Evaluation Division NRaD
  390.         (formerly the Naval Ocean Systems Command (NOSC)), voice is
  391.  
  392.  
  393.  
  394. Chimiak                                                         [Page 7]
  395.  
  396. RFC 1453             Comments on Video Conferencing           April 1993
  397.  
  398.  
  399.         multicasted over XTP/FDDI.  A simple multicast is
  400.         distributed to a group with a latency of around 25 ms, where
  401.         the latency represents delay from the voice signal from the
  402.         microphone to the audio signal to the speaker.  This group
  403.         is currently doing research on an n-party multicast of voice
  404.         (telephone conference-call paradigm [n x n multicast]).
  405.  
  406.    (4)  Commercially, Starlight Networks Inc., migrated a subset of
  407.         XTP into the transport layer of its video application
  408.         server.  By using XTP rate control, full-motion, full-screen
  409.         compressed video is delivered at a constant 1.2 Mbps, over
  410.         switched-hub Ethernet to viewstations.  This network
  411.         delivers at least 10 simultaneous video streams.
  412.  
  413.    Therefore, XTP has been used in applications that were previously
  414.    placed over IP or even a data link layer.
  415.  
  416. 5.  Policy versus Mechanism
  417.  
  418.    Separating protocol policies and mechanisms [XTPbk] permits adoption
  419.    of new policies without altering offered mechanisms.  An excellent
  420.    example is UVa's Partially Error Controlled Connections (PECC).  This
  421.    control system maximizes error control in such a way that receiving
  422.    FIFOs are never starved i.e., the application, driver, or operating
  423.    system buffer control, and not the transport layer becomes the
  424.    bottleneck.
  425.  
  426.    Because XTP is mechanism-rich and policy-tolerant, this very dynamic
  427.    error control policy mechanism is possible.  Separating policy and
  428.    mechanism permits an error-control or flow-control policy to adapt to
  429.    the data link layer conditions without shutting down a connection and
  430.    rebuilding (or multiplexing) a new one on a different protocol stack.
  431.    This may also provide an easier way for a network management
  432.    subsystem to maintain a desired QOS.
  433.  
  434. 6.  Summary
  435.  
  436.    Remote conferencing presents new opportunities for research,
  437.    business, and administration.  Although some are proposing that only
  438.    classical circuit-switched mechanisms be used, most network engineers
  439.    are searching for ways to use the new features of FDDI, SMDS, and ATM
  440.    in multimedia applications such as remote conferencing.  Some new
  441.    applications have been placed directly on a data link layer.  New
  442.    Transport/Network layer combinations have been proposed and are being
  443.    tested.  It is believed that consideration should be given to XTP as
  444.    a possible solution because its forum membership includes commercial,
  445.    government, and research institutions, some of which have implemented
  446.    various applications that contribute to an overall remote-
  447.  
  448.  
  449.  
  450. Chimiak                                                         [Page 8]
  451.  
  452. RFC 1453             Comments on Video Conferencing           April 1993
  453.  
  454.  
  455.    conferencing application.
  456.  
  457. 7.  References
  458.  
  459.    [CCP92]     Schooler, E., "An Architecture for Multimedia Connection
  460.                Management", in Proceedings of the 4th IEEE ComSoc
  461.                International Workshop on Multimedia Communications,
  462.                Monterey, CA, April 1992.
  463.  
  464.    [CHIM92]    Chimiak, W., "The Digital Radiology Environment", IEEE
  465.                JSAC, Vol. 10, No. 7, pp. 1133-1144, September 1992.
  466.  
  467.    [Delta-t]   Watson, R. W., "Delta-t Protocols Specification",
  468.                Lawrence Livermore Laboratory, April 15, 1983.
  469.  
  470.    [GAM-T-103] French Ministry of Defense, "GAM-T-103 Military
  471.                Real-Time Local Area Network Reference Model
  472.                (Transfer Layer)", February 7, 1987.
  473.  
  474.    [PECC92]    Dempsey, B., Strayer, T.  and Weaver A., "Adaptive Error
  475.                Control for Multimedia Data Transfer", in Proceedings
  476.                of the IWACA 92, Munich, Germany, pp. 279-288, March
  477.                1992.
  478.  
  479.    [PVP81]     Cole, R., "PVP - A Packet Video Protocol", W-Note 28,
  480.                Information Sciences institute, University of
  481.                California, Los Angeles, CA, August 1981.
  482.  
  483.    [RFC1045]   Cheriton, D., "VMTP: Versatile Message Transaction
  484.                Protocol Specification", RFC 1045, Stanford
  485.                University, February 1988.
  486.  
  487.    [RFC998]    Clark, D., Lambert, M., and L. Zhang, "NETBLT: A Bulk
  488.                Data Transfer Protocol", RFC 998, MIT, March 1987.
  489.  
  490.    [RFC1193]   Ferrari, D., "Client Requirements For Real-Time
  491.                Communication Services", RFC 1193, UC Berkeley,
  492.                November 1990.
  493.  
  494.    [RFC1190]   Topolcic, C., Editor, "Experimental Internet Stream
  495.                Protocol: Version 2 (ST-II)", RFC 1190, CIP Working
  496.                Group, October 1990.
  497.  
  498.    [SCHU92]    Schulzrinne, H., "A Transport Protocol for Audio and
  499.                Video Conferences and other Multiparticipant
  500.                Real-Time Applications", Internet Engineering Task
  501.                Force, Internet-Draft, October 1992.
  502.  
  503.  
  504.  
  505.  
  506. Chimiak                                                         [Page 9]
  507.  
  508. RFC 1453             Comments on Video Conferencing           April 1993
  509.  
  510.  
  511.    [UVAVOICE92] Weaver, A. C. and McNabb, J.F., "Digitized Voice
  512.                 Distribution Using XTP and FDDI", Transfer, Vol. 5,
  513.                 No.  6, pp. 2-7 (November/December 1992).
  514.  
  515.    [XTP92]     Xpress Transfer Protocol, version 3.6, XTP Forum,
  516.                1900 State Street, Suite D, Santa Barbara, California
  517.                93101 USA, January 11, 1992.
  518.  
  519.    [XTPbk]     Strayer, W.T., Dempsey, B.J., and Weaver, A.C., "XTP:
  520.                The Xpress Transfer Protocol", Addison-Wesley
  521.                Publishing Company, Inc., 1992.
  522.  
  523.    [XTPRACE]   Rebensburg, K. and Miloucheva, I., "The Use of XTP in a
  524.                Large European Communication Project", XTP Forum
  525.                Research Affiliate Annual Report, Document 92-183,
  526.                pp. 105-112, 1992.
  527.  
  528. Security Considerations
  529.  
  530.    Security issues are discussed in section 2.1.
  531.  
  532. Author's Address
  533.  
  534.    William J. Chimiak
  535.    Department of Radiology
  536.    Bowman Gray School of Medicine
  537.    Medical Center Boulevard
  538.    Winston-Salem, NC 27157-1022
  539.  
  540.    Phone: 919-716-2815
  541.    EMail: chim@relito.medeng.wfu.edu
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Chimiak                                                        [Page 10]
  563.